Context information is typically used to encapsulate and describe the state of a particular aspect of a data processing system. For example, a transaction context describes an associated transaction that is currently in existence on the system. Such a transaction may have one or more descendants, in which case nested contexts would be used to describe the hierarchy of transactions.
The concept of nested contexts and distributing them between systems is not new, for example, an OMG Transaction Service (OTS) specification, currently available from Object Management Group, describes nested transactions and their propagation between processes. In the case of OTS, however, details of the entire hierarchy are propagated between systems.
The use of context information in transaction processing will be used for explanatory purposes. FIGS. 1A and 1B illustrate the prior art process in detail.
Referring first to FIG. 1A, an application 30 may initiate a transaction (such as to book a vacation) in a “superior” (or coordinating) environment 10. The term“environment” should be construed as encompassing both hardware in a data processing or computer system and software that must be installed and executed on that system in order to perform a described transaction. When a transaction is instantiated by process A, context information is created about that transaction. This information typically consists of a transaction identifier (e.g. ABC). Transaction ABC may require interaction with a backend resource such as a database 40. Again context information is created indicating that this is the case. Furthermore, the transaction ABC may need to instantiate work on another distributed system. If this is the case, then the context information needs to be propagated to the secondary or subordinate environment 20.
Propagation of the context information is achieved via a Context Propagation Message (CPM) 1001 shown in FIG. 1B. A context propagation message includes details of the transaction(s) owned by superior environment 10. Thus the CPM message 1001 includes the transaction identifier ABC, details of its parent (NULL in this case) and details of its ancestors or children (again NULL).
Upon receiving CPM 1001 in subordinate environment 20, process B extracts information from the message to recreate the context hierarchy present in superior environment 10. Again, subordinate transaction ABC may require interaction with backend systems such as databases 50, 60.
Superior transaction ABC has overall control. When application 30 indicates that the transaction is to complete, superior transaction ABC commits (completes) its changes to backend database 40 and also instructs subordinate transaction ABC to complete its part of the work. Responsive to an instruction to complete successfully (henceforth known as a complete instruction) from superior ABC, subordinate transaction ABC commits its changes to databases 50, 60.
It can be seen that the processing involved when there is a parent transaction only (no children) is relatively simple.
The situation becomes far more complex with nested transactions and therefore nested context information. FIGS. 2A and 2B illustrate this.
Referring first to FIG. 2A, a transaction and associated sub-transactions are initiated by an application (not shown). As before, transaction initiation causes the creation of associated context information by process A. Thus process A creates contexts C1, C2 and C3. Once again, it is necessary for some of the work to be done in a secondary or subordinate environment 20. Consequently a CPM 1002 (as shown in FIG. 2B) is sent to environment 20.
CPM 1002 includes the details of the context information being propagated. This comprises an identifier for each transaction (C1, C2, C3) and whether that transaction has a parent and/or any children. The CPM 1002 is used by process B to replicate the hierarchical information as part of process B.
Again, the superior transaction has overall control (C1). A superior transaction is responsible for determining when an instruction to complete can successfully be invoked on a particular sub-transaction (subordinate transaction). Thus C2 has responsibility for C3 and C1 has responsibility for C2. Chains of responsibility are propagated up the hierarchy both in and across superior and subordinate environments. For example, responsibility for subordinate transaction C1 in environment 20 is owned by superior transaction C1 in environment 10. Consequently superior C1 has overall control of both superior and subordinate environments. Propagation of such responsibility to a context's parent happens each time a “complete” instruction is received at that context.
FIGS. 2A and 2B depict a fully workable and known solution. However performance testing in multi-CPU machines has revealed that, even with gigabit Ethernet connections between systems, it is possible for network bandwidth to become a performance bottleneck when propagating contexts across a network. Therefore it is desirable for such contexts to be as concise as possible to minimize the likelihood of such a bottleneck occurring.
One way in which the amount of data used to propagate the contexts between systems can be reduced is to compress the data at the sending side and decompress it at the receiving side. While this reduces the burden on network bandwidth, it increases the burden on the system processors during the compression and decompression of the data. A secondary concern is that the two parties involved in the data transmission must agree on the compression/decompression algorithm to be used, adding to the complexity of the data transfer.